1. Field of Invention
The present invention relates generally to the field of interprocess communication. More particularly, this invention relates to an interprocess communication mechanism that enables the synchrony semantics of each communication to be controlled by external entities called monitors, such that: (1) communication may be redirected to such external entities transparently to the sender and receiver of the communication and (2) the monitors can determine the semantics of a completed communication as they desire.
2. Background of the Invention
Interprocess communication (IPC) monitoring enables the examination of any IPC between a source and a destination. IPC monitoring is useful for a variety of purposes, including debugging, logging, and security. For example, a monitor may collect communication state for the purpose of debugging a program consisting of several independent tasks. Also, a monitor can be used to filter communication data or control the communication rate for security purposes.
Transparent monitoring means that the source and destination are not aware that they are being monitored.
This has two advantages: (1) the system can control the insertion and removal of monitors without interacting with either the source or destination, and (2) the source and destination protocols do not need to take into account the possibility that they may be monitored. Traditional systems make no attempt to support transparent monitoring. Using Mach-style ports (see K. Loepere, Mach 3 Kernel Principles, Open Software Foundation and Carnegie Mellon University, 1992), the source and destination hold rights that must be revoked in order to insert a monitor, so at least one must be notified before such a change can occur safely. The Pebble microkernel enables transparent redirection of source IPCs using its portals to implement customized IPC, but the redirection is not transparent to the destination because it sees that the message is from the redirected task, not the original (see E. Gabber et al, Building Efficient Operating Systems from User-level Components in Pebble, in Proceedings of the 1999 USENIX Annual Technical conference, 1999).
Other IPC mechanisms, such as Clans & Chiefs (see J. Liedtke, Clans & Chiefs, in Architektur von Rechensystemen, 1992, in English) and IPC Redirection (see, “Flexible Access Control Using IPC Redirection,” HotOS 1999), enable monitors to intercept and forward IPCs while claiming to be the original source of the IPC. Thus, the destination receives the IPC from the source, not the monitor, so it need not know that an IPC is being monitored. Unfortunately, such mechanisms are not truly transparent because the kernel's IPC semantics are not preserved when a monitor intercepts an IPC. Modern microkernels implement a synchronous IPC semantics, which means that the source is blocked until the destination is ready to receive the IPC or an error occurs (e.g., the destination task is killed or a timeout expires). When destination commences receipt, the IPC is sent to the destination and the source unblocks. Unfortunately, if a monitor is inserted on an IPC path, the source is unblocked when the IPC is received by the monitor, not the destination. This may result in some anomalous behaviors, such as: (1) the source assuming that IPCs have been delivered to the destination before they really have; (2) the source terminating IPCs due to timeout expiration even though the destination is ready, but because the monitor was not ready; and (3) the source assuming that the IPC was delivered reliably to the destination when an error may have occurred.
What is needed is that the system (i.e., the kernel and the monitors) control the synchrony of each communication, so that the communication appears to the sender and destination to be implemented according to the same semantics regardless of whether a monitor is present or not. Further, the system may choose arbitrary actions upon a communication, so the interprocess communication mechanism must permit the system to provide any desired semantics. Lastly, the interprocess communication mechanism must result in a system that is robust in the presence of errors.